Consumption layer query interface

ABSTRACT

A non-transitory computer-readable storage medium having stored thereon computer executable program code which, when executed on a computer system, causes the computer system to perform steps. The steps include receiving an indication of a selection of an entity type from a plurality of entity types each associated with a model layer framework, two or more of the model layer frameworks being different model layer frameworks, and the selection of the entity type being based on a user interface interaction on a first user interface where the plurality of entity types are displayed independent of the different model layer frameworks, receiving an indication of a selection of an entity from the selected entity type, receiving an indication of a selection of an element from the selected entity, and generating a service based on the entity and item.

This application claims the benefit of U.S. Provisional PatentApplication 61/912,290 filed on Dec. 5, 2013 entitled “ADVANCED BUSINESSAPPLICATION PROGRAMMING (ABAP) QUERY INTERFACE”, U.S. Provisional PatentApplication 61/912,254 filed on Dec. 5, 2013 entitled “SERVICE ADAPTIONLANGUAGE (SADL) ENTITY” and U.S. Provisional Patent Application61/912,287 filed on Dec. 5, 2013 entitled “SERVICE ADAPTION LANGUAGE(SADL) AS A TIMELESS CONSUMPTION LAYER”, the entire contents each ofwhich are incorporated herein by reference. This application is relatedto co-pending application entitled “BUSINESS OBJECT MODEL LAYERINTERFACE”, attorney docket number 0045-064001/130924US02 and co-pendingapplication entitled “CONSUMPTION LAYER FOR BUSINESS ENTITIES”, attorneydocket number 0045-065001/131193US02, the entire contents each of whichare incorporated herein by reference.

FIELD

Embodiments relate to computing, and in particular, to systems andmethods for consumption layer utilization (e.g., query interfacedevelopment) of decoupled consumption and business model layers.

BACKGROUND

Databases and business objects are highly useful tools allowing users tomanage complex relationships between large amounts of different types ofdata. When data is requested to be read, analyzed, and returned in ade-normalized view from a database, in general a user interface (UI),web service, data export and the like will formulate a use scenario,such as a query, search, or free search having features, to thedatabase. The database can include a large number of instantiatedbusiness objects, entities that include attributes and associations withother business objects.

Typically, different data models and business object frameworks areimplemented in a complex architecture. For example, an integration ofeach business model into different user interface (UI) technologies caninclude complex integrations with differing frameworks. Therefore,systems implemented using the UI technologies and the different businessmodels result in different components and the point-to-pointintegrations. The point-to-point integrations can result in a high totalcost of development (TCD) for the business object framework development,maintenance, and the integration effort for the system. Experiences forapplication developers can be less than ideal, because each of thedifferent integrations have no harmonized look and feel. Again this canresults in a high TCD for the developer as well as any partners and/orcustomers, because no common concepts, tooling and integrations are inplace in the current art. As a result, a developer has to learn point topoint integration. In addition, a combination of different integrationsmay not be possible or may require a significant amount of manualeffort.

SUMMARY

One embodiment includes a non-transitory computer-readable storagemedium having stored thereon computer executable program code which,when executed on a computer system, causes the computer system toperform steps. The steps include receiving an indication of a selectionof an entity type from a plurality of entity types each associated witha model layer framework, two or more of the model layer frameworks beingdifferent model layer frameworks, and the selection of the entity typebeing based on a user interface interaction on a first user interfacewhere the plurality of entity types are displayed independent of thedifferent model layer frameworks, receiving an indication of a selectionof a select a entity from the selected entity type, receiving anindication of a selection of an element from the selected entity, andgenerating a service based on the entity and item.

Implementations can include one or more of the following features. Forexample, the steps may further include mapping a data source to theselected item of the selected entity. The steps may further includegenerating a second user interface based on the first interface andconfigured to display data based on the view. The steps may furtherinclude interfacing with a database including a plurality of corecapabilities, and delegating execution of a service implementing one ofthe core capabilities to the database. The steps may further includeinterface with two or more databases where a first database includes aplurality of core capabilities, and a second database includes aplurality of convenience capabilities, mapping the plurality of corecapabilities and the plurality of convenience capabilities using aregistry, and delegating execution of a service implementing one of theplurality of core capabilities or the plurality of conveniencecapabilities to the database using the map.

For example, the steps may further include interfacing with two or moredatabases each database including a plurality of capabilities, andexposing the plurality of capabilities in a uniform manner such that theplurality of capabilities are indistinguishable based on the two or moredatabases. The steps may further include checking during runtime, if acapability is enabled and delegating execution of a service implementingthe capability if the capability is enabled. The steps may furtherinclude receiving a service indicating a query to be executed, the queryrequesting data from at least two databases, disassociating elements ofthe query into a first sub-element and a second sub-element based on theat least two databases, delegating the first sub-element and the secondsub-element to a corresponding database, and associating the results ofthe delegation as the result of the query. The entity may be associatedwith an in memory database. The in memory database may be a HighPerformance Analytic Appliance (HANA).

Another embodiment includes a non-transitory computer-readable storagemedium having stored thereon computer executable program code which,when executed on a computer system, causes the computer system toperform steps. The steps include reading metadata associated with aService Adaptation Definition Language (SADL) entity, translating themetadata into Structured Query Language (SQL) artifacts, and building aruntime load indicating how to retrieve data from a data source based onthe SQL artifacts.

Implementations can include one or more of the following features. Forexample, the runtime load may be a SADL runtime. The steps may furtherinclude generating a service based on two or more entity elementsselected from two or more entity types, wherein the metadata isassociated with the generated service. The runtime load may beconfigured to execute the SQL artifacts in response to a request fordata. The SQL artifacts include SQL views, SQLScript and applicationfunctions. The SQL artifacts may include a Query-Pushdown to HighPerformance Analytic Appliance (HANA).

Yet another embodiment includes an apparatus. The apparatus includes aplurality of query engines including a first query engine configured toimplement in-memory database specific features, and a query interfaceconfigured to determine a query engine, of the plurality of queryengines, to call based on an associated consumer level query execution.

Implementations can include one or more of the following features. Forexample, the query interface may be further configured to map anapplication programming interface corresponding to a databaseimplementation of a capability and a consumer request to implement thecapability. The query interface may be further configured todisassociate elements associated with a larger operation such that eachelement is pushed-down to a corresponding query engine for each element.The apparatus further includes a condition provider registry configuredto provide at least one of application specific and framework specificrestrictions for data manipulation.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will become more fully understood from the detaileddescription given herein below and the accompanying drawings, whereinlike elements are represented by like reference numerals, which aregiven by way of illustration only and thus are not limiting of theexample embodiments and wherein:

FIGS. 1A and 1B illustrate a block diagram of an interaction betweenobjects according to at least one example embodiment.

FIG. 2 illustrates a block diagram of a business object data modelaccording to at least one example embodiment.

FIGS. 3A and 3B illustrate block diagrams of consumption layer objectsand model layer frameworks.

FIG. 4 illustrates a block diagram of a Business Entity interfacingbetween consumption layer objects and model layer frameworks accordingto at least one example embodiment.

FIG. 5 illustrates a block diagram of a system according to at least oneexample embodiment.

FIGS. 6A, 6B and 6C illustrate flowcharts according to at least oneexample embodiment.

FIGS. 7A and 7B illustrate user interfaces according to at least oneexample embodiment.

FIGS. 8A-8F illustrate a signal flow according to at least one exampleembodiment.

FIG. 9 illustrates another flowchart according to at least one exampleembodiment.

FIGS. 10A and 10B illustrate feature intersections according to at leastone example embodiment.

FIGS. 11 and 12 illustrate block diagrams of systems including a queryinterface according to at least one example embodiment.

FIG. 13 illustrates a block diagram of a system according to at leastone example embodiment.

It should be noted that these Figures are intended to illustrate thegeneral characteristics of methods, structure and/or materials utilizedin certain example embodiments and to supplement the written descriptionprovided below. These drawings are not, however, to scale and may notprecisely reflect the precise structural or performance characteristicsof any given embodiment, and should not be interpreted as defining orlimiting the range of values or properties encompassed by exampleembodiments. For example, the positioning of structural elements may bereduced or exaggerated for clarity.

DETAILED DESCRIPTION OF THE EMBODIMENTS

While example embodiments may include various modifications andalternative forms, embodiments thereof are shown by way of example inthe drawings and will herein be described in detail. It should beunderstood, however, that there is no intent to limit exampleembodiments to the particular forms disclosed, but on the contrary,example embodiments are to cover all modifications, equivalents, andalternatives falling within the scope of the claims. The use of similaror identical reference numbers in the various drawings is intended toindicate the presence of a similar or identical element or feature.

FIGS. 1A and 1B illustrate a block diagram of an interaction betweenobjects according to at least one example embodiment. As shown in FIG.1A a consumption layer object 105A is communicatively coupled with amodel layer object 110A. In the example of FIG. 1A, the consumptionlayer object 105A may be any object (e.g., an element of a computingsystem) configured to consume (e.g., read, write, update, etc.) data.The model layer object 110 may be a business object (e.g., a class ofobjects) defining objects of the business world including, for example,a data model, functions, relationships and an associated business logic(described in more detail below with regard to FIG. 2). The model layerobject 110A may be implemented on a framework (e.g., Advanced BusinessApplication Programming (ABAP)). In one or more example implementations,there may be several frameworks on which several model layer objects110A are implemented. Accordingly, developing consumption layer objects105A may require special knowledge of and special skill for utilizingeach of the several model layer objects 110A.

Therefore, example implementations may include an interface object 115configured to implement several model layer objects 110B in a commonstructure such that consumption layer objects 105B may utilize a singlestructure in order to interface with several model layer objects 110B.In other words, interface object 115 presents a uniform structure orframework utilized by a developer of a consumption layer object 105B. Inother words, a business object associated with a model layer object 110Bmay be de-coupled from the framework used to implement the businessobject such that a developer of a consumption layer object 105B needs nospecial knowledge of and/or special skill in order to utilize thebusiness object.

FIG. 2 illustrates a block diagram of a business object data modelaccording to at least one example embodiment. A notation for describingdata models in relational database management systems is sometimescalled Entity-Relationship Diagrams (ER-Diagrams). ER-Diagrams may beused to design database tables and their relationships. In severalobject-oriented programming languages technologies exist that map thesedata models to class references or representations of the programminglanguage sometimes called OR-Mapping. A business object (e.g., inobject-oriented software development) describes objects of the businessworld including, for example, a data model, functions, relationships andan associated business logic (e.g., BOPF).

As shown in FIG. 2 a business object data model 200 may be, for example,related to a sales object. The business object data model 200 mayinclude at least one business object. For example, the business objectdata model 200 may include a business object 205 (e.g., sales order), abusiness object product 215 and a business object partner 220. Abusiness object item 210 and the business object partner 220 may benodes of the business object 205 (e.g., sales order). Further, thebusiness object item 210 may also have an associated node (e.g.,business object product 215). In the example of FIG. 2, the businessobject 205 may be a sales order object. However, other business objectsare within the scope of this disclosure. The business object 205 maylink to the business object partner 220 in order to, for example,indicate a business partner (e.g., customer) that has placed a salesorder. The business object 205 may link to the business object item 210(e.g., a sales order item) in order to indicate what is ordered. Thebusiness object item 210 may indicate, for example, a Product ID, aquantity ordered (e.g., GrossAmount, NetAmount), and/or the like. Thebusiness object item 210 may link to the business object product 215.The business object product may indicate internal information about theordered product (e.g., ID, Description, and/or the like).

In some systems the business objects (e.g., business object 205,business object item 210, and the like) may be elements of differentsystems (e.g., sales order management (SO) systems, product managementsystems, inventory management systems, enterprise resource planning(ERP) systems, and the like). Accordingly, business objects may beimplemented on different frameworks or model layers (e.g., model layerobject 110A). For example, the frameworks may include business objectprocessing framework (BOPF), business object layer (BOL), serviceprovider interface (SPI), or low level representations such as DDICtables/views, core data services, HANA views, and the like. Therefore,in order to integrate sales object, a developer may require specialknowledge of and special skill for utilizing each of the frameworks oraccessing these data models.

However, according to example embodiments, an interface object orframework or entity (e.g., interface object 115) may be used tode-coupled the business object from the framework used to implement thebusiness object such that a developer needs no special knowledge ofand/or special skill in order to utilize the business object. In otherwords, the developer may only need the skills associated with a singleinterface (e.g., interface object 115) instead of the skills associatedwith the many frameworks that business objects can be associated with.

FIGS. 3A and 3B illustrate block diagrams of consumption layer objectsand model layer frameworks. In the example shown in FIGS. 3A and 3B,there are several blocks associated with a consumption layer and thereare several blocks associated with a model layer. The blocks associatedwith the consumption layer include floor plan manager (FPM) 305A, 305B(e.g., SAP Floor Plan Manager®), gateway (GW) 310A, 310B (e.g.,NetWeaver Gateway®), and the like.

FPM is a framework for developing self-service applications using WebDynpro® for Java®. FPM is configured to ensure that self-serviceapplications follow a consistent pattern or road map. GW is a set ofadd-ons configured to provide the ability to make an HTTP(S) request inorder to access data.

The blocks associated with the model layer include business object layer(BOL) 320A, 320B, business object processing framework (BOPF) 325A,325B, core data services (CDS) 330A, 330B, data dictionary (DDIC) 335A,335B, service provider infrastructure (SPI) 340A, 340B, enterprisesearch model 345A, 345B, and the like.

In order to abstract from different DBMS DDIC is a native AdvancedBusiness Application Programming (ABAP) component configured to definedatabase tables and views. These tables and views can natively behandled in ABAP as first class citizens. Persistence classes in objectoriented (OO) ABAP provides classes that are representations of tables.The classes combine data models with business logic. ABAP persistenceclasses are a typical OR-Mapping infrastructure.

Business Object Processing Framework (BOPF) is a framework configured toprovide an end-to-end development experience. BOPF supports the modelingof the data model and takes care for the persistency. BOPF enables theimplementation of business logic as actions, determinations andvalidations. BOPF is also configured to enable a consistent logical unitof work (LUW) handling (e.g., the span of time during which any databaseupdates must be performed). Business Object Layer (BOL) is anabstraction layer for legacy code. BOL provides an infrastructure tobuild a business model on top of legacy code with a harmonizedApplication Programming Interface (API) configured to enable amodel-based consumption in higher layers. The framework supportsLUW/transactional handling but does not care about the way the data ispersisted.

Service Provider Interface (SPI) is similar to BOL but does not providedesign time to model business objects. The SPI is defined via APIs.

Enterprise Search Model is an infrastructure supporting fast search andquery operations on replicated data in Text Retrieval and informationExtraction (TREX) (e.g., a search engine) or on original data in a HighPerformance Analytic Appliance (HANA) (e.g., an in-memory,column-oriented, relational database management system). The enterprisesearch model is an infrastructure configured to support fast search andquery operations on replicated data. Enterprise search models are viewson the data that can be connected with associations. Therefore,Enterprise Search Model can be described as Business Objects withoutbusiness logic. The associations are used for navigation purposes ongeneric applications consuming these models.

A Business Object Repository (BOR) is a registry for function modules.BOR functions can be registered to enable a harmonized consumption.

A core data services (CDS) is a concept for HANA and ABAP on HANA inorder to describe business objects as first class citizens. CDS isconfigured to enable the definition of query languages native syntax(e.g., DDIC, HANA) to work with the business objects.

As shown in FIG. 3B, one or more of the FPM 305B, GW 310B, and the likemay be communicatively coupled to one or more of the BOL 320B, BOPF325B, CDS 330B, DDIC 335B, SPI 340B, enterprise search model 345B, andthe like. Typically the coupling is via a software interface (e.g.,custom software code) that is different for each coupled pairing. Inother words, the interface coupling FPM 305B to BOL 320B is differentthan the interface coupling FPM 305B to BOPF 325B. Because the interfacecoupling is different for each coupled pairing, developing consumptionlayer objects (e.g., FPM 305B, GW 310B, and the like) may requirespecial knowledge of and/or special skill for utilizing each of theseveral model layer objects (e.g., BOL 320B, BOPF 325B, CDS 330B, DDIC335B, SPI 340B, enterprise search model 345B, and the like).

FIG. 4 illustrates a block diagram of a business entity interfacingbetween consumption layer objects and model layer frameworks accordingto at least one example embodiment. In the example shown in FIG. 4,there are several blocks associated with a consumption layer and thereare several blocks associated with a model layer. The blocks associatedwith the consumption layer include floor plan manager (FPM) 405 (e.g.,SAP Floor Plan Manager®), gateway (GW) 410 (e.g., NetWeaver Gateway®),and the like. The blocks associated with the model layer includeenterprise search model 415 (e.g., NetWeaver Enterprise Search®),business object layer (BOL) 420, business object processing framework(BOPF) 425, core data services (CDS) 430, data dictionary (DDIC) 435,service provider infrastructure (SPI) 440, and the like. Straddling theconsumption layer and the model layer is a business entity 445 module orobject or abstraction. Business entity 445 may be configured toimplement several model layer objects (e.g., enterprise search model415, BOL 420, BOPF 425, CDS 430, DDIC 435, SPI 440, and the like) in acommon structure such that consumption layer objects (e.g., FPM 405, GW410, and the like) may utilize a single structure in order to interfacewith several model layer objects. In other words, business entity 445presents a uniform structure or framework utilized by a developer of aconsumption layer object (e.g., FPM 405). In other words, a businessobject associated with a model layer object (e.g., BOL 420) may bede-coupled from the framework used to implement the business object suchthat a developer of a consumption layer object (e.g., FPM 405) needs nospecial knowledge of and/or special skill in order to utilize thebusiness object.

Accordingly, business entity 445 (or entity) may be a frameworkconfigured to enable consumption of different business object models,and other entity-based models, for example, DDIC tables and views, in auniform way. Knowledge of the details of the modeling frameworks, suchas BOPF or BOL is not required, as such the business entity 445 modelexposes all the required information to a user interface configured todevelop consumption layer objects (e.g., FPM 405).

Business entity 445 can be implemented using an adapter including aruntime interface or API, metadata and at least one interface associatedwith each of the model layer objects. The runtime interface may beconfigured to interface with the at least one interface and at least oneconsumption layer tool during an implemented operation (e.g., accessingdata associated with a business object). For example, the FPM may beconfigured to update an element data entry (e.g., completion date).Accordingly, the runtime interface may be configured to receive (orotherwise acquire) the element to be updated and the new data. Theruntime interface may access the appropriate interface and call,implement and/or execute the function, code, tool, and/or the likeassociated with the interface for updating the element data entry. Forexample, in an interpreted environment the runtime interface may map afunction, code and/or tool associated with a business object. Forexample, in a compiled environment, the runtime interface may becompiled together (e.g., as source code) with the interface to includethe function, code and/or tool associated with a business object.

Metadata may include any data and/or data associations for the runtimeinterface, the interface, and/or objects in the model layer (e.g., BOL420). For example, metadata may include business objects in an object inthe model layer, business object associations (e.g., as an ER-diagram),elements of a business object, function calls in a business object,and/or the like. The at least one interface may be configured toimplement several model layer objects (e.g., BOL 420) in a commonstructure such that consumption layer objects may utilize a singlestructure in order to interface with several model layer objects. Inother words, interface object presents a uniform structure or frameworkutilized by a developer of a consumption layer object. In other words, abusiness object associated with a model layer object may be de-coupledfrom the framework used to implement the business object such that adeveloper of a consumption layer object needs no special knowledge ofand/or special skill in order to utilize the business object.

According to example embodiments, a consumption layer artifact (e.g.,GW, FPM, ALV UI, views, and/or the like) can be built using any tooling(e.g., Eclipse and/or a WebIDE) on top of any business model withgeneric runtime support for query pushdown or transactional scenariosvia delegation to the business model runtime. For example, SADL can beused as a generic consumption layer and can be used for any UITechnology or other consumption scenarios (e.g., Excel-Export,Web-Services, Workflow Integration, and/or the like). The genericconsumption layer can enable capabilities including, for example, viewbuilding, providing an infrastructure to consume any ER-like businessmodel based on SADL, support Read-Only Optimized access viaQuery-Pushdown to HANA, support Transactional Scenarios delegating tothe business model runtime (e.g., BOPF runtime), native Integration intoexisting development environment (e.g of a UI Technology) withoutadditional repository, tooling or design time artifacts, reusableeditors (e.g. Eclipse or Web-IDE) supporting all scenarios can beprovided, and harmonized tooling with improved development experienceand lower TCD/TCO

FIG. 5 illustrates a block diagram of a system according to at least oneexample embodiment. As shown in FIG. 5, the system 500 includes FPM 405,GW 410, BOPF 425, BOL 420, CDS 430, DDIC 435, etc., and Business entity445 each described above. The system 500 further includes a ServiceAdaptation Definition Language (SADL) engine 505, acreate/read/update/delete (CRUD) module 510, a query module 515, adatabase 520 and an executable 530. As shown in FIG. 5, the BOPF 425includes a BOPF runtime 525. The database 520, the BOPF 425, the BOL420, the CDS 430 and the DDIC 435 are included in a model (ornormalized) layer. The SADL engine 505 and the business entity 445 areincluded in a consumption (or de-normalized) layer. The FPM 405, GW 410,adapter 535 and adapter 540 are included in a UI backend.

The CRUD module 510 may be configured to delegate calls to the businessmodel runtime. For example, a BOPF read may be delegated to the BOPFruntime 525. The query module 515 may be configured to delegate to theABAP Query Interface (described in more detail below) a query request(e.g. oData getEntitySet( )) such that the query request is executed onthe database 520 (e.g. HANA) with special features like text-search andpaging on the database 520.

The BOPF runtime 525 may call, implement and/or execute the function,code, tool, and/or the like in order to create, read, update and/ordelete an element data entry. For example, the BOPF runtime 525 may mapa function, code and/or tool associated with a business object includingdata associated with the database 520.

The executable 530 may load (e.g., begin execution) when runtimerelevant information is desired. For example, the executable 530 mayinclude associated metadata related to, for example, a business object.If the metadata is relevant for an action (e.g., function call, look-up,definition, and the like), the executable 530 may load and provide themetadata.

Adapter 535 may be configured to provide generic feeder classes betweenFPM 405 and SADL engine 505. A feeder class provides a link between anapplication (e.g., SADL engine 505) and a user interface (e.g., FPM405). For example, the feeder class may be based on a predefinedinterface definition, providing all (e.g., most, substantially all)necessary methods and corresponding signatures to standardize thecommunication between the application and the user interface. Adapter540 may be configured to provide code (e.g., Destination Point Code)delegating functions to the SADL runtime.

FIGS. 6A, 6B and 6C illustrate flowcharts according to at least oneexample embodiment. The steps described with regard to FIGS. 6A-6C maybe performed due to the execution of software code stored in a memory(e.g., at least one memory 1310) associated with an apparatus (e.g., asshown in FIG. 13) and executed by at least one processor (e.g., at leastone processor 1305) associated with the apparatus. However, alternativeembodiments are contemplated such as a system embodied as a specialpurpose processor. Although the steps described below are described asbeing executed by a processor, the steps are not necessarily executed bya same processor. In other words, at least one processor may execute thesteps described below with regard to FIG. 6A-6C.

FIG. 6A illustrates a design time scenario in which a developer (e.g.,an application developer) may be designing an application (e.g.,building a query) using a tool such as GW (e.g., GW 410). As shown inFIG. 6A, in step S605 a business entity type is selected. For example, aBOPF (e.g., BOPF 425) or a DDIC (e.g., 435) business entity type orframework may be selected. The selection may be performed using a userinterface as shown in, for example, FIG. 7A or 7B. For example, a windowassociated with the user interface may display at least one businessentity type for selection.

In step S610 a business entity (associated with the business entitytype) is selected. For example a table, a view, a procedure, a function,a routine and the like may be selected. The business entity may beassociated with one or more business object. For example, a tableincluding a manufacturing item may be associated with a bill of materialbusiness object, a sales order business object, an item business objectand the like. The selection may be performed using a user interface asshown in, for example, FIG. 7A or 7B. For example, a window associatedwith the user interface may display at least one business entity(associated with a selected business entity type) for selection.

In step S615 elements and associations are selected. For example, if thebusiness entity is a table or a view, at least one data object, field orkey of the table or view may be selected as an element. For example, ifthe business entity is a procedure, function or routine, an inputvariable (e.g., for create or update) or output (e.g., for a read) maybe selected as the element. For example, a table parent/child (e.g., anassociation between a field in one (parent) table and field in another(child) table) association may be selected as an association. Forexample, an association between business objects (e.g., an associationbetween a sales order business object and an item business object) maybe selected as an association. The selection may be performed using auser interface as shown in, for example, FIG. 7A or 7B. For example, awindow associated with the user interface may display at least oneelement and/or association (associated with a selected business entity)for selection.

In step S620 if the desired (e.g., all or substantially all) businessentities have been selected, processing continues to step S625.Otherwise, processing returns to step S610. In step S625 if the desired(e.g., all or substantially all) business entity types have beenselected, processing continues to step S630. Otherwise, processingreturns to step S605. For example, the developer may be developing atleast one query that spans across a plurality of business entities andbusiness entity types. Accordingly, the developer may first (but notnecessarily first) select the desired business entities andcorresponding elements/associations for a business entity type. Thedeveloper may then select a different business entity type and repeatthe process as many times as necessary to develop or generate thedesired query.

In step S630 a service is generated. The service may be based on theprevious selections. In other words, the service may be based on a querybased on the previous selections. Generating the service may includegenerating SADL metadata based on the previous selections. GeneratingSADL metadata may include converting the selectedentities/elements/associations into a data structure or metadata (e.g.,as described above). Generating SADL metadata may include translatinglanguage (or code) associated with the procedure(s) into a string ofsymbols having a common or standard language (e.g., machine language orportable language). Generating SADL metadata may include generatingmetadata including a mapping of relationships between business objects(e.g., a relationship between a sales order entry object and a salesorder item object).

Generating SADL metadata may include generating a SADL definition. Asadl:definition can contain a sadl:dataSource where the type of the datasource (for example, a business object), the binding (for example anentry path of the business object) and a name (which can be used asalias in an XML document), are specified. A syntactic analysis may beperformed on the data structure and/or the translated string of symbolsto ensure uniqueness of namespace prefixes.

In a sadl:definition, the sadl:resultSet can also be defined. Thesadl:resultSet can contain a sadl:structure with the attributes andsubstructures. In a sadl:atttibute, the name of the attribute and thebinding can be specified. The binding can contain, in a Xpath-likesyntax, an access path for mapping to the business object data. Forexample, such an approach can provide either direct business objectattribute access of the node as specified in the binding of thesadl:dataSource (for example using ‘/’ for subcomponent access in theattribute type) or business object attribute access with sub pathspecification via business object associations (for example with anamespace prefix such as “assoc:” or “ass:” to denote an association)using ‘/’ for the association links.

A sadl:definition can contain a list of XML namespace definitions,possibly including but not limited to the UUID of the SADL, the date andtime of the SADL (CreatelLastChange), one or more sadl:dataSourcedefinitions, a list of sadl:callbacks (can be empty), and asadl:resultSet. A sadl:dataSource can advantageously contain the data insome type. If the data source type is a business object node type, abinding can be defined. Especially when several data sources arespecified, naming of the data source can be very helpful. The datasource names can be used in the source definition as aliases todistinguish accesses to the different data sources. A sadl:callback cancontain the programming language of the callback, the callback's classname, the names of the target business object type, the target nodename, and the path ID of the callback. The callback can be used in anybinding definition where an association can occur by specifying thecallback name, for example with a prefix such as “clb:”. Filtering by anassociation filter can also be provided. Filter expressions can bedefined in brackets. In an implementation, an attribute binding canallow only one-to-one associations if a filter is not specified.

FIG. 6B illustrates a compile time scenario in which a developer (e.g.,an application developer) may be compiling an application usingincluding a query developed based on the steps described in FIG. 6A. Asshown in FIG. 6B, in step S635 a determination is made (e.g., by aprocessor) as to whether or not a runtime load (e.g., a SADL runtime) isavailable. For example, the runtime load may not be available because aruntime load has not been previously built or generated. If a runtimeload is available, processing continues to step S665 where a SADLruntime is called. Otherwise, processing continues to step S640.

In step S640 SADL is parsed. For example, parsing may include checkingthe syntax of the source code and creating a compiler format ofadaptation data necessary to provide runtime access to application data.Parsing can include a check of the uniqueness of the namespace prefixes.Therefore a sadl:definition can contain a sadl:dataSource where the typeof the data source (for example, a business object), the binding (forexample an entry path of the business object) and a name (which can beused as alias in an XML document).

In step S645 a SADL entity metadata is read. For example, the generatedservice described above with regard to FIG. 6A may include an associatedmetadata (e.g., SADL metadata). This associated metadata may be read asSADL entity metadata during this compile operation.

In step S650 at least one of the parsed SADL and the SADL entitymetadata may be translated into structured query language (SQL)artifacts. Artifacts may include SQL views, SQLScript and theApplication Functions. Accordingly, translating SADL entity metadata mayinclude generating SQL statements representing elements of a querydefined by the SADL entity metadata. Additional, non-limiting, examplesof SQL artifacts being part of the generated statements: includerequested elements (query output), restricting clauses representing userselection, restrictions corresponding to the limitations in the userauthorizations, grouping and sorting criteria, parameters,localization/language indicators, and the like.

In step S655 a runtime load is built. For example, the runtime load canbe built (e.g., compiled) based on at least one of the parsed SADL, theSADL, entity metadata and the translated SQL artifacts. The runtime loadcan contain an execution plan indicating how to retrieve data from adata source (e.g., database 520). In other words, the runtime loadindicates how a query defined by the SADL, metadata should be executedon the data source. For example, whether or not the query should bedelegated to the data source for execution, Building the runtime loadmay include generating runtime metadata. In one example implementation,each runtime load is associated with unique runtime metadata (e.g., onefile per runtime load). In an alternative implementation, runtimemetadata is aggregated (e.g., one file for all runtime loads). In anexample implementation, the runtime load may be configured to serve asfast access to the SADL metadata and can be invalidated and rebuilt whenany relevant property of the corresponding business entity changes. Thisinvalidation can be based on checksums over the properties of theincluded entities, or timestamps represented the last change.

In step S660 a determination is made as to whether or not each desiredruntime load is built. If the desired runtime load(s) are built, theprocess ends. Otherwise, processing returns to step S635.

FIG. 6C illustrates a runtime scenario in which an end user (e.g., anoperator of a client device) may be using an application including aquery developed based on the steps described in FIG. 6A and compiledbased on the steps described in FIG. 6B. As shown in FIG. 6C, in stepS670 a client component executes a query. For example, a user interface(e.g., an application GUI) developed and compiled as described above maybe executing on a client computer (e.g., a personal computer, a handheld device, and the like). During execution the user interface triggersa request for data resulting in the execution of the query.

In step S675 a back-end service is executed. For example, a server(e.g., a networked computing device including at least one processor andmemory) including, for example, at least one of the consumption layers(and associated components/elements/modules) described above may includea service (e.g., the service including associated SADL metadatadescribed above). The service may be communicatively coupled via theserver to the user interface executing on the client computer.Accordingly, the service may be triggered to execute based on theexecution of the query on the client computer.

In step S680 a SADL runtime (e.g., runtime load) is called. The compiledcomponent (e.g., runtime load) described above with regard to FIG. 6B iscalled. Calling the SADL runtime causes the compiled code to execute onthe server including at least one of the model layers (and associatedcomponents/elements/modules) described above.

In step S685 runtime metadata is read. As described above, when theruntime load is built, runtime metadata may be generated. This runtimemetadata is read by the server (e.g., a processor of the server) inorder to load information associated with the query (e.g., whether ornot the query is to be executed by the database or by the server).Finally, in step S690 the query executes on the database.

FIGS. 7A and 7B illustrate user interfaces (UI) according to at leastone example embodiment. The user interfaces (e.g., UI 700, UI 750) maybe used to develop a user interface for use by an end user to, forexample, view/create/delete data stored in a database implemented using,a BOPF framework. The user interface for use by an end user may includea portion of UI 700, UI 750. The user interface for use by an end usermay compiled and/or interpreted prior to and/or while in use by the enduser.

As shown in FIG. 7A, a gateway (GW) service builder UI 700 configured tobuild a gateway (e.g., GW 310A, 310B). The GW service builder UI 700 mayinclude windows 705, 710, 715. The first window 705 may include adropdown list of business objects and business object services.Selecting (e.g., clicking on, hovering over) one of the items indropdown list, for example, SalesOrder 720, may open the second window710. The second window 710 may be configured to enable a developer tomap a data source to the selected (e.g. selected item in window 705)item. In this example implementation, the developer can choose from alocal or remote system and data source.

For example, the second window 710 shows a selection of a SADL Entitytype 725 and a BOPF˜SalesOrder˜Root type 730 (which may be enabledfollowing selection of the SADL Entity type 725). Selecting (e.g.,clicking on, hovering over) the BOPF˜SalesOrder˜Root type 730 may openthe third window 715. The third window 715 may be configured to enablethe developer to select the type of framework associated with the SADLentity. In this example implementation, the developer can choose from aBOPF, DDIC Table or CDS as the type of framework associated with theSADL entity of which BOPF 735 is selected resulting in the return (ormapping) of the SalesOrder˜Root 740 to the BOPF˜SalesOrder˜Root type 730and thus the SalesOrder 720. In example implementations, data populatingone or more of the windows 705, 710, 715 may be based on (or generatedusing) metadata stored in, for example, meta-data 1325 described below.Accordingly, a developer using UI 700 does not have to have completeknowledge of the details of the modeling frameworks, such as BOPF orBOL.

As shown in FIG. 7B, a gateway (GW) service builder UI 750 configured tobuild a gateway (e.g., GW 310A, 310B). The GW service builder UI 750 mayinclude windows 755, 760, 765. The first window 755 may include adropdown list of business objects and business object services.Selecting (e.g., clicking on, hovering over) one of the items indropdown list, for example, SalesOrder 770, may link (or associate, bindor correspond) data entered in the second window 760 to the selecteditem (e.g., SalesOrder 770). The second window 760 may be configured toenable a developer to map a data source to the selected (e.g. selecteditem in the first window 755) item. In this example implementation, thedeveloper can create a property having a property name, choose an ABAPfield to link to the property and bind the property to an item selectedfrom a SADL Entity in the third window 765.

For example, the second window 760 shows the creation of a propertycalled MY_SELLER_ID which is linked or mapped to ABAP field SELLER_IDwith a property binding of Seller, SELLER_ID. In addition, anassociation binding has been created where Items having a value (amount)greater than 1000 are included. In an example implementation, itemsassociated with the SADL Entity may be dragged and dropped from thethird window 765 to a field in the second window 760. For example itemSeller, SELLER_ID may be dragged from the third window 765 to an fieldin the property binding column of the second window 760. In exampleimplementations, data populating one or more of the windows 755, 760,765 may be based on (or generated using) metadata stored in, forexample, meta-data 1325 described below. Accordingly, a developer usingUI 700 does not have to have complete knowledge of the details of themodeling frameworks, such as BOPF or BOL.

FIGS. 8A-8E illustrate a signal flow according to at least one exampleembodiment. As shown in FIGS. 8A-8E, an example business objectSalesOrderOverview 805 includes associated items (which may also beconsidered as business objects) sales order 810, business partner 815and address 820. Sales order 810 includes an associated node (e.g.,another business object) items 825. Items 825 include associated itemsitem 830, product 835 and description 840.

Initially, in block 845 a user interface (e.g., a UI described above ora UI developed using a UI described above) triggers a CRUD service(e.g., a read service). For example, the UI (e.g., via interaction of anend user) triggers an action (e.g., click on a button on the UI) thatcauses a processor on a computer executing (or displaying) the UI totrigger a read of at least one data element associated with a businessobject. As shown in FIG. 8A, the CRUD service may be associated with,for example, a SalesOrderOverview 805 business object. In an exampleimplementation, the UI triggers functionality (e.g., a service, aprogram function) associated with CRUD module 510.

In block 850 CRUD (e.g., CRUD module 510) delegates to a runtime of theselected business object. For example, the CRUD may map the triggeredservice to a corresponding service in the selected business object. TheCRUD the delegates (e.g., calls or forwards) the requested execution ofthe service to the selected business object. For example, as shown inFIG. 8B, the service can be delegated to one or more of sales order 810,business partner 815 or address 820 (each including a correspondingruntime configured to execute a service).

In block 855 CRUD are executed by the selected business object. Forexample a read operation is executed by the selected business object(e.g., by a processor associated by the business object). For example,as shown in FIG. 8C, one or more of the sales order 810, businesspartner 815 or address 820 executes the service (e.g., a read) on anassociated datastore (e.g., memory, database, organized data, and thelike). Although not shown, if the service is associated with anassociated node (e.g., items 825), executing the service may includesome interaction with an item (e.g., description 840) of the associatednode. In other words, in an example implementation, a service callrequesting the description of an item in a sales order may result in acall to a service associated with description 840.

In block 860 a notification(s) and/or message(s) are returned by theselected business objects. For example, the notification and/or messagemay include information and/or data associated with the triggeredservice. For example, if the service includes a create service (e.g.,create a new sales order, item, business partner, and the like), anotification may include an indication as to whether or not the createservice was successful. For example, if the service includes a readservice, a message may include data associated with the read service(e.g., the result of a query) and a notification may include information(e.g., a number of rows, date/time, and the like) about the data. Asshown in FIG. 8D, one or more of the sales order 810, business partner815 and address 820 may return the notification and/or message resultingfrom execution of the service by one or more of the sales order 810,business partner 815 and address 820.

In block 865 the notification(s) and/or message(s) are mapped from theselected business object to the consumption layer. For example, the CRUDmodule 510 may include metadata that is configured to mapnotification(s) and/or message(s) that are framework (e.g., theframework associated with the business object) specific to a common orintermediate language or structure (e.g., SADL or XML) for use in theconsumption layer. For example, as shown in FIG. 8E, a business partner815 may be mapped from “BuPa” in the model layer to “My_BuPa” in theconsumption layer.

Finally, in block 870 the mapped notification(s) and/or message(s) areexposed. For example, the notification(s) and/or message(s) are madeavailable to the UI so that the processor associated with the UI maytake appropriate action. For example, the processor may display resultson the UI. The processor may display a window indicating completion,success, failure and/or the like of the triggered service. Examples ofbusiness objects, services and/or the like described above with regardto FIGS. 8A-8E are illustrative in nature and do not limit the subjectmatter of this disclosure in any way.

FIG. 9 illustrates another flowchart according to at least one exampleembodiment. The steps described with regard to FIG. 9 may be performeddue to the execution of software code stored in a memory (e.g., at leastone memory 1310) associated with an apparatus (e.g., as shown in FIG.13) and executed by at least one processor (e.g., at least one processor1305) associated with the apparatus. However, alternative embodimentsare contemplated such as a system embodied as a special purposeprocessor. Although the steps described below are described as beingexecuted by a processor, the steps are not necessarily executed by asame processor. In other words, at least one processor may execute thesteps described below with regard to FIG. 9

As shown in FIG. 9, in step S905 a business entity type from a pluralityof business model types is selected. For example, a window, panel, dropdown, and/or the like (e.g., window 705, 755) may show a list ofbusiness model types (e.g., as an expandable list) showing businessmodel types associated with a model layer. The window, panel, drop down,and/or the like may be generated using the steps described above withregard to FIG. 6. In other words, the window, panel, drop down, and/orthe like may be generated based on the published business objects(organized as business model types). Each of the business model typesmay be implemented of a different model layer framework (e.g., BOPF,CDS, and the like). For example, a business partner business object maybe implemented on a different framework than a product business object.The developer can access the business model types without knowledge ofhow to implement the underlying framework for each of the business modeltypes.

In step S910 a business model from the selected business model type isselected. For example, selecting a business model type may expose atleast one business model. In other words, if a window includes a list ofbusiness model types as an expandable list, the expandable list may beexpanded based on the business model type and at least one businessmodel. Selecting a business model types may expose at least one businessmodel which in turn may also be selected.

In step S915 an item from the selected business model is selected. Forexample, continuing the expandable list example, each expanded businessmodel may expose at least one item which in turn may also be selected.In example embodiments, the item may have an associated data. Forexample, the item may correspond to or be associated with a column in adatabase (e.g., relational database).

In step S920 whether or not additional data is desired is determined. Ifadditional data is desired, processing returns to step S905. Otherwise,processing continues to step S925. For example, in an exampleimplementation, data may be acquired from one or more data structures(e.g., database, HANA) associated with a model layer framework(s) (e.g.,BOPF, CDS, and the like). One data (e.g., an item of a business object)of interest may be associated with a first business model typeassociated with a first model layer framework which is selected during afirst iteration. In a second or subsequent (e.g., multiple iterations)another data (e.g., another item of a business object) of interestassociated with the first (e.g., the same) or a second business modeltype associated with the first (e.g., the same) or a second model layerframework may be selected. If all of the data of interest is selected,processing continues to map, use, associate, link, and the like thedata.

In step S925 a view based on the business model(s) and business modelitem(s) is built. A view may be configured to allow a display ofdifferent perspectives of the same data structure (e.g., database, HANA)or combination of data structures (e.g., databases, HANA). Views maydefine which business object items (e.g., table column) and stored data(e.g., row) are viewed. The access to the data may be simplified and/orpersisted by presenting the structure of the data from at least onedatabase table into a single named view (which can be used like a table)that can hide, not show, not select and/or eliminate unnecessary datawhile contributing desired data. In an example implementation, each ofthe selected nodes from the selected business objects may be organizedinto a view. The view may include a mechanism to limit and/or focus theamount and/or type of data. For example, at least one of theaforementioned business objects may be associated with purchasing anairline flight. Although the business object exposes a multitude ofdetails for the purchase, the view may limit the exposed information toe.g. amount and date, hiding the credit card information and customerpreferences.

In step S930 data sources of the business model are mapped to the view.{Inventor: Seems like there is more to the how of this} For example, agenerated view may be purpose bound, for example, to an intended UI oruse case. The associated business entities may be designed keepingreusability in mind, avoiding redundancy and so on. For example, whenusing a sales order, it will have associations to a buyer, seller andowner, which may all be modelled as business partners. When binding thebusiness partner data to a view, one follows, for example, threedifferent associations from the sales order entity to the same businesspartner entity. The mapping serves to avoid having the same element,like business partner name, three times in the ui—map it once to sellername, buyer name and owner name, respectively. For example, as discussedabove, in a SADL definition, a result set can be defined. The result setcan contain a (SADL) structure with the attributes and substructures. Ina (SADL) attribute, the name of the attribute and the binding can bespecified. Accordingly, as shown in FIGS. 7A and 7B, a developer can mapthe business model to the view using data source attributes and/orassociation binding. In an alternative embodiment, steps S925 and/or 930are performed before step S920. In other words, the decision to add datamay be performed after building a view and mapping data sources.

In step S935 a user interface based on view is generated. For example, auser interface may include a number of fields. Each field may be linked,associated, tied to, and the like an item in the aforementioned view.The user interface may include other items as well. For example, theuser interface may include data entry fields, drop down lists, pictures,information panels, and/or the like. For example, the user interface mayinclude a field and/or drop down list such that an end user of the userinterface can select or limit data associated with the view andtherefore the user interface.

At least one example embodiment implements general purpose applicationprogramming interface (API) configured to be used in severalimplementation scenarios. For example, in a Value Help (or F4 help)scenario, a search help tool may combine the benefits of this UI conceptwith an In-Memory database (e.g., high-performance analytic appliance(HANA)) results. For example, in a HANA fuzzy (or freestyle) search toolan error tolerant search can be achieved such that misspelling of searchterms may return relevant results. In other words, an end user of the UImay enter “trevel expence” where both “travel” and “expense” are clearlymisspelled. According to example embodiments, results may be returnedthat include the correct spelling (e.g., “travel expense”).

In another example implementation, a graphical user interface (GUI)configured to display a list viewer (e.g., ABAP List Viewer or ALV) maybe used to view a list used in, for example, various reports. Accordingto an example embodiment, an integrated data access differs may be usedin order to push-down a request associated with the GUI. In thisintegrated data access (IDA) approach, the ALV directly retrieves thedata from the database, by performing a query considering all services(sorting, filtering, paging, etc.). The application and the end userparameterize the query executed by the ALV IDA. Only the displayed datais read from the database. In addition, features like the HANA FuzzySearch can be integrated into an API configured to execute the IDAapproach.

FIGS. 10A and 10B illustrate feature intersections according to at leastone example embodiment. According to at least one example embodiment, inorder to support a plurality of implementation scenarios associated witha query push-down, a database interface configured to push-down commonUI services like sorting, filtering and paging to the database may bedeveloped. Further, the database interface may be configured to enableHANA specific features (e.g. in order to support fuzzy search). Thequery interface may be referred to as an ABAP Query Interface (ABQI) orSADL Query Engine. The ABQI may also avoid SQL Injections by validatingthe input from an application and/or end-user interacting with the API.In at least one example implementation, the ABQI shall ensure, that anydatabase query could be performed for any database.

In an example implementation, OpenSQL is a set of ABAP statements thatperform operations like reads, modifies or deletes data in any number ofdatabase frameworks. OpenSQL is independent of the database system, sothe syntax of the open SQL is uniform for all supported databases.OpenSQL statements may be passed to the database interface. The databaseinterface converts the OpenSQL to native SQL (e.g. DB2) and passes thenative SQL on to the database. Accordingly, using OpenSQL an applicationdeveloper can ignore database specific details (e.g. syntax, datatypes), since OpenSQL in combination with a data dictionary (DDic) mayprovide an ABAP-embedded abstraction layer. Using this exampleimplementation, common database features can be provided. However, if aparticular feature (e.g. paging) is not supported by one of theplurality database management systems, this feature may not be exposedvia OpenSQL. As a result HANA specific features may not be supported byOpenSQL.

In the example embodiment shown in FIG. 10A, a first databaseabstraction 1000 is illustrated as a feature intersection using adatabase interface based on an open source database language (e.g.,OpenSQL or MySQL). In FIG. 10A three database systems 1005, 1010 1015are shown (although example embodiments are not limited thereto).Database system 1015 is illustrated as a HANA. HANA (e.g., SAP™ HANA)may be a data warehouse appliance for processing high volumes ofoperational and transactional data in real-time. HANA may use in-memoryanalytics, an approach that queries data stored in random access memory(RAM) instead of on hard disk or flash storage. HANA may have specialcapabilities or features not implemented in other (e.g., non In-Memorydatabase) systems.

Using OpenSQL, the capabilities identified as capabilities 1035 may beimplemented because the capabilities 1035 can be implemented in each ofthe three database systems 1005, 1010 1015. However, using OpenSQLcapabilities 1020, 1025 and 1030 may not be implemented because thecapabilities 1035 cannot be implemented in each of the three databasesystems 1005, 1010 1015. In an alternative implementation one or more ofcapabilities 1020 and 1025 may be implemented in OpenSQL if one or moreof capabilities 1020 and 1025 are common features or capabilities eventhough the common feature or capability may not be implemented in alldatabase systems. However, HANA special capabilities or features may notimplemented in OpenSQL.

In another example implementation, a feature super-set implements adatabase interface configured to expose any database capability orfeature including those that are not supported by all databases. Forexample, HANA specific features may be supported in a feature super-setimplementation. In order to provide HANA specific features or byoffering database specific features in general with such a super-setapproach, two problems should be addressed. First, support for differentdatabase management systems includes providing an infrastructureconfigured to register database specific implementations. Second, acapability service (e.g., a consumer of the query interface) may beconfigured to check if a feature is supported on the current database,therefore the database interface may be configured to expose thesupported feature set of the current database management system. In anexample implementation, the feature super-set for should be chosen toimplement an ABAP Query Interface (ABQI) if a HANA system is included.

In the example embodiment shown in FIG. 10B, a second databaseabstraction 1050 is illustrated as a feature intersection using adatabase interface based on ABQI configured to implement a featuresuper-set. As shown in FIG. 10B three database systems 1055, 1060 1065are shown (although example embodiments are not limited thereto).Database system 1065 is illustrated as a HANA. Using the ABQI, thecapabilities identified as capabilities 1080 may be implemented eventhough the capabilities 1080 may not be implemented in each of the threedatabase systems 1055, 1060 1065. One or more of capabilities 1070 and1075 may be implemented in the ABQI if one or more of capabilities 1070and 1075 are common features or capabilities even though the commonfeature or capability may not be implemented in all database systems.

FIGS. 11 and 12 illustrate block diagrams of systems including a queryinterface according to at least one example embodiment. As shown inFIGS. 11 and 12, the system may include at least one module, engineand/or object. The module, engine and/or object may be implemented dueto the execution of software code stored in a memory (e.g., at least onememory 1310) associated with an apparatus (e.g., as shown in FIG. 13)and executed by at least one processor (e.g., at least one processor1305) associated with the apparatus. However, alternative embodimentsare contemplated such as a system embodied as a special purposeprocessor. Although the module, engine and/or object are described asbeing executed by a processor, the module, engine and/or object are notnecessarily executed by a same processor. In other words, at least oneprocessor may execute the software code configured to implement themodule, engine and/or object described in relation to FIGS. 11 and 12.

According to example embodiments, the consumer of ABQI (e.g. Value Helpand ALV) pushes down as many capabilities and/or features as possible tothe database. Therefore the ABQI consumer interface should be offermultiple features to as many consumers as possible. The provider API canbe implemented a plurality of times for each supported database.Therefore, a consumer API may be configured to enable and/or implementcore capabilities and/or features (e.g. sorting, paging, and the like),convenience capabilities and/or features (e.g., an authority check), andselection parameters (e.g., those not supported by the DBMS natively).Selection Parameters (also called Range Tabs or Select Options) may bethe ABAP-way of defining filters in user interfaces. According toexample embodiments, selection parameters may be part of the ABQIconsumer interface. ABQI internally maps the selection parameters to acondition enriching the WHERE clause.

The ABQI implementation of the consumer API may be configured to map theconvenience capabilities and/or features to the core capabilities and/orfeatures. A provider API may be implemented for each individualdatabase. The core feature set covers the database features: sorting,paging, conditions, text search, aggregation and grouping, and/or thelike. For example, in most use cases the displayed data should beretrieved from the database in order to minimize the response time andmemory consumption in ABAP. Paging on the database may be possible if anauthorization check is also performed on the database.

As shown in FIG. 11, the system 1100 includes an ABQI 1105, a HANA queryengine 1110, other query engine 1115, a HANA 1125, other database 1130and a condition provider registry 1135. The other query engine 1115 andthe other database 1130 may be one of a plurality of query engines anddatabases for which the ABQI 1105 has access (e.g., a communicative linkand permission to Create/Read/Update/Delete).

In an example implementation, a registry for different database specificimplementations may be implemented based on the separation of the ABQI1105 (e.g., as a consumer API or interface) and a query engines (e.g.,as a provider API or interface). The registry may be configured to mapthe ABQI 1105 (e.g., as a consumer API) to corresponding capabilities ofthe database via the query engines (e.g., as a provider API). Forexample, using a business add in (BAdI) infrastructure specificimplementation can be registered for each different database managementsystem (DBMS). As a BAdI fallback implementation an OpenSQL variant ofthe provider API can be implemented. During runtime ABQI calls the BAdIto get the provider for the DBMS of a current operation.

ABQI 1105 may be configured to determine a query engine (e.g., HANAquery engine 1110, query engine 1115, and the like) to call for anassociated consumer level query execution. For example, ABQI 1105 maycall HANA query engine 1110 if a capability, a query, and the like isassociated with a HANA and query engine 1115 if a capability, a queryand the like is associated with a DB2 database. For example, ABQI 1105may include the aforementioned registry. The registry may be configuredto maintain a correspondence between a capability (e.g., sorting,paging, and the like) for a DBMS and a query engine routine or API forthe capability as implemented in the specific database. In other words,the registry may be used to link or map an API for a specific databaseimplementation of a capability and a consumer request to implement thecapability. In this way, a database independent consumer API may supporta plurality of different DBMS based on provision of a provider API forDB-specific implementations.

ABQI 1105 may be further configured to separate, disconnect,disassociate, and/or the like elements of a larger operation such thateach element is pushed-down to a corresponding query engine for eachelement. For example, a first element of an operation (e.g., a query)may be associated with a HANA and a second element of an operation maybe associated with a DB2 database. The ABQI 1105 may be configured todisassociate the first element and the second element from the largeroperation and call the appropriate query engine. The ABQI 1105 may besubsequently configured to rebuild the larger operation from the datareturned from the associated query engines.

The condition provider registry 1135 may be configured to provideapplication or framework specific restrictions for data manipulation.The condition provider registry 1135 may be evaluated by an ABQI andtransform the restrictions into an intermediate post fix format andpassed to a query engine for use in a where clause of a query.

A capability service may be configured to enable the offering of HANAspecific features in combination with the support of different DBMS. Forexample, on the one hand specific features may be consumed. On the otherhand the applications (as a consumer) should run on any DBMS.Accordingly, in an example implementation a service specifying whichfeatures are supported by the current DBMS may be implemented. The queryengine (e.g., as a provider API) may include a signature for thecapability service. Each database implementation can define whichfeatures are supported. The configuration is exposed via ABQI 1105 andeach consumer has to check during runtime, if a particular feature isenabled or not.

As shown in FIG. 12, the system 1200 includes the ABQI 1105, the HANAquery engine 1110, the other query engine 1115, the HANA 1125, and theother database 1130. The ABQI 1105 further includes capability service1205 configured to expose capabilities 1210 and 1215 associated with theHANA query engine 1110 and the other query engine 1115, respectively.The capability service 1205 may be configured to expose capabilities1210 and 1215 in a uniform manner such that capabilities 1210 and 1215are indistinguishable to a consumer even though the capabilities 1210and 1215 operate on different databases.

FIG. 13 illustrates a block diagram of a system according to at leastone example embodiment. As shown in FIG. 13, the system (or apparatus)1300 includes at least one processor 1305 and at least one memory 1310.The at least one processor 1305 and the at least one memory 1310 arecommunicatively coupled via bus 1315. The system 1300 may be, forexample, an element of a computing device (e.g., a cloud computingdevice or a server).

In the example of FIG. 13, the system 1300 may be at least one computingdevice and should be understood to represent virtually any computingdevice configured to perform the methods described herein. As such, thesystem 1300 may be understood to include various standard componentswhich may be utilized to implement the techniques described herein, ordifferent or future versions thereof. By way of example, the system 1300is illustrated as including the at least one processor 1305 (e.g., asilicon based processor), as well as the at least one memory 1310 (e.g.,a non-transitory computer readable storage medium) respectively.

Thus, as may be appreciated, the at least one processor 1305 may beutilized to execute instructions stored on the at least one memory 1310,so as to thereby implement the various features and functions describedherein, or additional or alternative features and functions. Of course,the at least one processor 1305 and the at least one memory 1310 may beutilized for various other purposes. In particular, it may beappreciated that the at least one memory 1310 may be understood torepresent an example of various types of memory and related hardware andsoftware which might be used to implement any one of the modulesdescribed herein. Systems and/or methods described below may includedata and/or storage elements. The data and/or storage elements (e.g.,data base tables) may be stored in, for example, the at least one memory1310.

As shown in FIG. 13, the at least one memory 1310 includes a businessentity module 1320 and a meta-data datastore 1325. The business entitymodule 1320 includes a consumption layer interface module 1330 and amodel layer interface module 1335. The consumption layer interfacemodule 1330 includes a CRUD module 1340. The model layer interfacemodule 1335 includes a runtime 1345.

The system 1300 may also include a network interface 1360communicatively coupled to bus 1315. The network interface 1360 isconfigured to interface with one or more servers 1370A, 1370B, 1370C,1370D, 1370E via network 1365. Network 1365 may be any network (e.g.,internet or intranet). The servers 1370A, 1370B, 1370C, 1370D, 1370E maybe configured to implement at least one framework associated with amodel layer (e.g., enterprise search model 415, BOL 420, BOPF 425, CDS430, DDIC 435, SPI 440, and the like).

The business entity module 1320 may be configured to publish businessobjects as and/or in association with a business entity. Accordingly,the model layer interface module 1335 may be configured to interfacewith at least one model layer framework (e.g., enterprise search model415, BOL 420, BOPF 425, CDS 430, DDIC 435, SPI 440, and the like). And,the consumption layer interface module 1330 may be configured tointerface with at least one consumption layer tool (e.g., FPM 405, GW410, and the like).

The CRUD 1340 may be configured to delegate calls to a runtime (e.g.,runtime 1345). For example, a read may be delegated to the runtime 1345.For example, the CRUD 1340 may map a triggered service to acorresponding runtime (e.g., a service in a business object). The CRUDthen delegates (e.g., calls or forwards) the requested execution of theservice to the selected business object.

The runtime 1345 may be configured to call, implement and/or execute thefunction, code, tool, and/or the like in order to create, read, updateand/or delete an element data entry. For example, the runtime 1345(e.g., BOPF runtime 525) may map a function, code and/or tool associatedwith a business object including data associated with a database (e.g.,database 520).

Some of the above example embodiments are described as processes ormethods depicted as flowcharts. Although the flowcharts describe theoperations as sequential processes, many of the operations may beperformed in parallel, concurrently or simultaneously. In addition, theorder of operations may be re-arranged. The processes may be terminatedwhen their operations are completed, but may also have additional stepsnot included in the figure. The processes may correspond to methods,functions, procedures, subroutines, subprograms, etc.

Methods discussed above, some of which are illustrated by the flowcharts, may be implemented by hardware, software, firmware, middleware,microcode, hardware description languages, or any combination thereof.When implemented in software, firmware, middleware or microcode, theprogram code or code segments to perform the necessary tasks may bestored in a machine or computer readable medium such as a storagemedium. A processor(s) may perform the necessary tasks.

Specific structural and functional details disclosed herein are merelyrepresentative for purposes of describing example embodiments. Exampleembodiments, however, be embodied in many alternate forms and should notbe construed as limited to only the embodiments set forth herein.

It will be understood that, although the terms first, second, etc. maybe used herein to describe various elements, these elements should notbe limited by these terms. These terms are only used to distinguish oneelement from another. For example, a first element could be termed asecond element, and, similarly, a second element could be termed a firstelement, without departing from the scope of example embodiments. Asused herein, the term “and/or” includes any and all combinations of oneor more of the associated listed items.

It will be understood that when an element is referred to as being“connected” or “coupled” to another element, it can be directlyconnected or coupled to the other element or intervening elements may bepresent. In contrast, when an element is referred to as being “directlyconnected” or “directly coupled” to another element, there are nointervening elements present. Other words used to describe therelationship between elements should be interpreted in a like fashion(e.g., “between” versus “directly between,” “adjacent” versus “directlyadjacent,” etc.).

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of exampleembodiments. As used herein, the singular forms “a,” “an” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“comprises,” “comprising,” “includes” and/or “including,” when usedherein, specify the presence of stated features, integers, steps,operations, elements and/or components, but do not preclude the presenceor addition of one or more other features, integers, steps, operations,elements, components and/or groups thereof.

It should also be noted that in some alternative implementations, thefunctions/acts noted may occur out of the order noted in the figures.For example, two figures shown in succession may in fact be executedconcurrently or may sometimes be executed in the reverse order,depending upon the functionality/acts involved.

Unless otherwise defined, all terms (including technical and scientificterms) used herein have the same meaning as commonly understood by oneof ordinary skill in the art to which example embodiments belong. Itwill be further understood that terms, e.g., those defined in commonlyused dictionaries, should be interpreted as having a meaning that isconsistent with their meaning in the context of the relevant art andwill not be interpreted in an idealized or overly formal sense unlessexpressly so defined herein.

Portions of the above example embodiments and corresponding detaileddescription are presented in terms of software, or algorithms andsymbolic representations of operation on data bits within a computermemory. These descriptions and representations are the ones by whichthose of ordinary skill in the art effectively convey the substance oftheir work to others of ordinary skill in the art. An algorithm, as theterm is used here, and as it is used generally, is conceived to be aself-consistent sequence of steps leading to a desired result. The stepsare those requiring physical manipulations of physical quantities.Usually, though not necessarily, these quantities take the form ofoptical, electrical, or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like.

In the above illustrative embodiments, reference to acts and symbolicrepresentations of operations (e.g., in the form of flowcharts) that maybe implemented as program modules or functional processes includeroutines, programs, objects, components, data structures, etc., thatperform particular tasks or implement particular abstract data types andmay be described and/or implemented using existing hardware at existingstructural elements. Such existing hardware may include one or moreCentral Processing Units (CPUs), digital signal processors (DSPs),application-specific-integrated-circuits, field programmable gate arrays(FPGAs) computers or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise, or as is apparent from the discussion,terms such as “processing” or “computing” or “calculating” or“determining” of “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical, electronicquantities within the computer system's registers and memories intoother data similarly represented as physical quantities within thecomputer system memories or registers or other such information storage,transmission or display devices.

Note also that the software implemented aspects of the exampleembodiments are typically encoded on some form of non-transitory programstorage medium or implemented over some type of transmission medium. Theprogram storage medium may be magnetic (e.g., a floppy disk or a harddrive) or optical (e.g., a compact disk read only memory, or “CD ROM”),and may be read only or random access. Similarly, the transmissionmedium may be twisted wire pairs, coaxial cable, optical fiber, or someother suitable transmission medium known to the art. The exampleembodiments not limited by these aspects of any given implementation.

Lastly, it should also be noted that whilst the accompanying claims setout particular combinations of features described herein, the scope ofthe present disclosure is not limited to the particular combinationshereafter claimed, but instead extends to encompass any combination offeatures or embodiments herein disclosed irrespective of whether or notthat particular combination has been specifically enumerated in theaccompanying claims at this time.

What is claimed is:
 1. A non-transitory computer-readable storage mediumhaving stored thereon computer executable program code which, whenexecuted on a computer system, causes the computer system to performsteps comprising: receive an indication of a selection of an entity typefrom a plurality of entity types each associated with a model layerframework, two or more of the model layer frameworks being differentmodel layer frameworks, and the selection of the entity type being basedon a user interface interaction on a first user interface where theplurality of entity types are displayed independent of the differentmodel layer frameworks; receive an indication of a selection of anentity from the selected entity type; receive an indication of aselection of an element from the selected entity; and generate a servicebased on the entity and item.
 2. The non-transitory computer-readablestorage medium of claim 1, the steps further comprising: map a datasource to the selected item of the selected entity.
 3. Thenon-transitory computer-readable storage medium of claim 1, the stepsfurther comprising: generate a second user interface based on the firstinterface and configured to display data based on the view.
 4. Thenon-transitory computer-readable storage medium of claim 1, the stepsfurther comprising: interface with a database including a plurality ofcore capabilities; and delegate execution of a service implementing oneof the core capabilities to the database.
 5. The non-transitorycomputer-readable storage medium of claim 1, the steps furthercomprising: interface with two or more databases, wherein a firstdatabase includes a plurality of core capabilities, and a seconddatabase includes a plurality of convenience capabilities; map theplurality of core capabilities and the plurality of conveniencecapabilities using a registry; and delegate execution of a serviceimplementing one of the plurality of core capabilities or the pluralityof convenience capabilities to the database using the map.
 6. Thenon-transitory computer-readable storage medium of claim 1, the stepsfurther comprising: interface with two or more databases each databaseincluding a plurality of capabilities; and expose the plurality ofcapabilities in a uniform manner such that the plurality of capabilitiesare indistinguishable based on the two or more databases.
 7. Thenon-transitory computer-readable storage medium of claim 1, the stepsfurther comprising: check during runtime, if a capability is enabled;and delegate execution of a service implementing the capability if thecapability is enabled.
 8. The non-transitory computer-readable storagemedium of claim 1, the steps further comprising: receive a serviceindicating a query to be executed, the query requesting data from atleast two databases; disassociate elements of the query into a firstsub-element and a second sub-element based on the at least twodatabases; delegate the first sub-element and the second sub-element toa corresponding database; and associate the results of the delegation asthe result of the query.
 9. The non-transitory computer-readable storagemedium of claim 1, wherein the entity is associated with an in memorydatabase.
 10. The non-transitory computer-readable storage medium ofclaim 9, the in memory database is a High Performance Analytic Appliance(HANA).
 11. A non-transitory computer-readable storage medium havingstored thereon computer executable program code which, when executed ona computer system, causes the computer system to perform stepscomprising: read metadata associated with a Service AdaptationDefinition Language (SADL) entity; translate the metadata intoStructured Query Language (SQL) artifacts; and build a runtime loadindicating how to retrieve data from a data source based on the SQLartifacts.
 12. The non-transitory computer-readable storage medium ofclaim 11, wherein the runtime load is a SADL runtime.
 13. Thenon-transitory computer-readable storage medium of claim 11, wherein thesteps further comprise: generating a service based on two or more entityelements selected from two or more entity types, wherein the metadata isassociated with the generated service.
 14. The non-transitorycomputer-readable storage medium of claim 11, wherein the runtime loadis configured to execute the SQL artifacts in response to a request fordata.
 15. The non-transitory computer-readable storage medium of claim11, wherein the SQL artifacts include SQL views, SQLScript andapplication functions.
 16. The non-transitory computer-readable storagemedium of claim 11, wherein the SQL artifacts include a Query-Pushdownto High Performance Analytic Appliance (HANA).
 17. An apparatuscomprising: a plurality of query engines including a first query engineconfigured to implement in-memory database specific features; and aquery interface configured to determine a query engine, of the pluralityof query engines, to call based on an associated consumer level queryexecution.
 18. The apparatus of claim 17, wherein the query interface isfurther configured to map an application programming interfacecorresponding to a database implementation of a capability and aconsumer request to implement the capability.
 19. The apparatus of claim17, wherein the query interface is further configured to disassociateelements associated with a larger operation such that each element ispushed-down to a corresponding query engine for each element.
 20. Theapparatus of claim 17, further comprising: a condition provider registryconfigured to provide at least one of application specific and frameworkspecific restrictions for data manipulation.